Link to this headingSAML (Security Assertion Markup Language)

• Good for Single-Sign On (SSO)
• Works on redirections

Duo SAML Vulns
Duo How SAML Works

Use SAML Raider

How SAML Works:

1. The User Logins in to a Identity Provider. The Identity Provider generates a SAML Response.
2. The Users browser forwards the SAML response to Service Provider
3. The Service Provider Verifies the Signature that is included in the SAML Response
4. If the signature is validated that it uses the identity to validate.

Link to this headingIdentity Provider

EntityID: Global Unique Name for the Service Provider <EntityDescriptor entityID="https://beertent.com/concert">
Assertion Consumer Service (ACS): URL where the SAML assertition will be sent. https://beertent.com/saml/consume/
ACS Validator: A regular expression (regex) that ensures the SAML assertion is sent to the correct ACS. Used for Service Provider Initiated Logins ^https:\/\/beertent\.com\/saml\/consume\/$
Attributes: Data that is passed to the Service Provider
RelayState: Not required. Deep linking for SAML. This tells the Service Provider where to take the user once they’ve successfully logged in. https://beertent.com/taps/lager/
SAML Signature Algorithm: SHA-1 or SHA-256. Less commonly SHA-384 or SHA-512.

X.509 Certificate: The Identity Provider certificate used to verify the signature of the metadata of the SAML assertion.

Issuer URL: Identifier with info for the Identity Provider. <saml:Issuer>https://access.wristbandtent.com/saml2/idp/metadata.php</saml:Issuer>

SAML SSO Endpoint / Service Provider Login URL: The endpoint that is used to initiate authentication on the domain of the Identity Provider.

SAML SLO (Single Log-out) Endpoint: The endpoint that is used to close the session on the domain of the Identity Provider. https://access.wristbandtent.com/logout

Link to this headingService Provider Initiated Login Example

1. The user tries to access a resource on a Service Provider.
2. The Service Provider Generates a SAML Request to be sent to the Identity Provider.
3. After Generating the SAML Request the Service Provider redirects the user to the Identity Provider. (Usually a 302 redirect)
4. With the redirect the Browser passes the request from the Service Provider to the Identity Provider.
   • The Identity Provider Checks the Authentication
   • The Identity Provider Checks the Authorization of the user
5. The Identity Provider Creates a SAML Response to be passed through the browser to the Service Provider.

Link to this headingStep 1

Fake Initial Request to the Service Provider:

Link to this headingStep 2

SAML Request Generated by the Service Provider:

Link to this headingStep 3

Uses a 302 Redirect to send the SAML Request to the Identity Provider Server.

RelayState: is the user that requested the data. This must be the same user in the response

302 Redirect Response from the server tSAML Request Generated by the Service Provider:

Link to this headingStep 4

Request to the Identity Server:

Link to this headingStep 5

ds:Signature: An XML Signature that protects the integrity of and authenticates the issuer of the assertion; the SAML assertion MAY be signed but doesn’t have to be. The example above contains two ds:Signature elements. The reason is that one is the message’s signature; the other is the Assertion’s signature.
saml:Assertion: Contains information about the user’s identity and potentially other user attributes.
saml:Subject: Specifies the principal that is the subject of all of the statements in the assertion.
saml:StatusCode: A code representing the status of the activity carried out in response to the corresponding request.
saml:Conditions: Specifies things like the time an Assertion is valid and that the Assertion is addressed to a particular Service Provider.
saml:AuthnStatement: States that the IdP authenticated the Subject of the Assertion.
saml:AttributeStatement: Contains Attributes that describe the Subject of the Assertion.

SAML Response Generated by the Identity Provider:

Link to this headingStep 6

After the Identity Provider has authenticated the user. It makes a Redirect so It can make a post to the server. The server knows the info from the session information

Redirection from the Identity Server after Login:

Link to this headingStep 7

Post with SAML Response to the Endpoint listed in AssertionConsumerServiceURL:

Link to this headingStep 8

Final Redirect back to the Original Address:

Link to this headingRequest Parameters

AssertionConsumerServiceURL: Identifies where the IdP should send the SAML Response to after authentication
Destination: Indicates the address to which the request should be sent (IdP)
ProtocolBinding: Typically accompanies the AssertionConsumerServiceURL attribute; defines the mechanism by which SAML protocol messages will be transmitted
saml:Issuer: Identifies the entity that generated the request message

Link to this headingResponse Parameters

• Response
  • Issuer
  • Signature
    • Signed Info
      • Reference
  • Status
  • Assertion
    • Issuer
    • Signature
      • Signed Info
        • Reference
    • Subject
      • NameID
    • Conditions
      • AudienceRestriction
    • AuthnStatement
    • AttributeStatement
      • Attribute
      • Attribute
      • Attribute
      • Attribute

Link to this headingEnveloped Signature

Link to this headingAttacking SAML

1. Modify username, email address, userID or other fields so see if it is signed.
2. Remove the signature and see if it accepts the response
3. Try Injecting a Comment into the SAML

• This can be used to register a new user admin<!--comment-->@example.com. Since the comment is removed it passes it to the server as [email protected]

4. Replay the SAML to test for repeated logins
5. Test XML for XXE and other XML attacks
6. Test CSRF Attacks. Check if it has RelayState and is checked from the original request.

Hacking SAML

Checklist:

• Test whether the server is checking the notbefore, notafter dates.
• Test whether the server is checking the Audience
• Test whether or not the SP accepts an Assertion without a Signature (Signature Exclusion)
• Test whether or not the SP is susceptible to XML Signature Wrapping (XML Signature Wrapping)
• Test whether or not the SP verifies that the Assertion came from a trusted IdP (Certificate Faking)
• Test whether or not the SP creates more than a single session per Assertion (Assertion Replay - may or may not be considered a bug by itself)
• Test whether or not the SP is vulnerable to XXE (XML eXternal Entity via SAML)
• Test whether or not the SP is vulnerable to XSLT (Extensible Stylesheet Language Transformation via SAML)
• If the target SP is serviced by an IdP to which you have a legitimate account on a different SP serviced by the same IdP, test whether or not the target SP accepts a valid Assertion meant for the valid SP (Token Recipient Confusion)

Link to this headingAttacking the signature

Use Cloned CA Cert:

1. Use SAML raider and Clone the Certificate
2. Save and Self sign

Use Cloned Cert Chain:

1. Use SAML raider and Clone the Certificate Chain
2. Save and Self sign

Use a Certificate from another Valid Service Provider:
This allows the data to be signed correctly but to the wrong Service Provider. This checks for Authorization bypass.

Link to this headingAttacking the XML Signature Wrapping

This is about moving the reference object to other parts of the XML tree with modified data.

Use SAML Raider Extension attacks

Link to this headingAttacking the XML

Example Attack:

Link to this headingAttacking the Token Recipient

Use a SAML targeted to another Recipient.
In the Request change the SubjectConfirmationData->Recipient value.

Link to this headingMalleability

Try duplicate tags to overwrite the needed